Transmission Control Protocol, TCP, is the most dominant protocol used in computer networking and on the Internet. TCP is a connection-oriented protocol, where devices at the end points, nodes, establish a connection before any data is sent during a TCP session.
In a session establishment phase, also known as a call set up phase, control data is passed between the nodes to establish a connection. The TCP protocol uses a three way handshake protocol to synchronize and to establish a TCP connection between two nodes. The TCP connection is initiated by a source node sending a synchronization, SYN, packet toward a destination node. The destination node acknowledges receipt of the SYN packet with a SYN-ACK packet sent toward the source node. Upon receipt of the SYN-ACK packet from the destination node, the source node responds with an acknowledgement, ACK, packet thereby concluding the establishment phase. During this 3-way handshake the hosts negotiate the connection settings.
Once the connection is set up, data transmission during the TCP session is controlled by three factors: the rate at which the source is willing to send data, controlled by the congestion control algorithm; the TCP window space advertised by the destination; and the rate at which data appears to be getting delivered to the destination as determined by the ACK packets received at the source from the destination.
Multipath TCP, MPTCP, allows a TCP session to use multiple paths to maximize resource usage. MPTCP has one main TCP flow and one or more TCP subflows for every TCP session and is capable of distributing load on all interfaces, for example by having the main TCP flow and the one or more TCP subflows on different interfaces such as a 3GPP-based interface and a Wi-Fi/WLAN based interface with separate IP-addresses. As the multiplexing of different connections is on TCP level it allows separate congestion control for each subflow.
MPTCP is an end-to-end protocol which requires both hosts to support MPTCP to benefit from MPTCP. Since, MPTCP is still in its early stage of deployment, probabilities that every host on the Internet supports MPTCP are very low. To overcome this problem and benefit from MPTCP even though both communicating hosts do not support MPTCP, an MPTCP proxy may be used to convert MPTCP flows to TCP and vice versa.
The main scenario for MPTCP is for a wireless device is capable of both LTE connection and Wi-Fi connection. For using MPTCP in an LTE-only case the main scenario is the case when an MPTCP capable wireless device is associated with two or more LTE PDN connections having their own IP addresses, making it possible to route an MPTCP main flow and one or more MPTCP subflows on different LTE carriers using these different IP addresses. In the case of two LTE PDN connections, there will exist at least two bearers which the MPTCP main flow and the subflow can be transmitted on; allowing RAN logic to have these bearers on different LTE carriers based on for example LTE Dual Connectivity or LTE Carrier Aggregation.
The need for IP-addresses is ever increasing, so to the point that IP addresses are considered as a scarce resource that need to be preserved. As the number of multipath capable wireless devices increases, this will further limit the availability of IP-addresses that may be assigned to a communication interface. There is a need to improve efficiency in IP address use during an MPTCP session.
The need for improved IP address efficiency has been addressed in the MPTCP specification in that the specification also supports MPTCP on a wireless device associated with one LTE PDN connection. A state of the art solution enabling multiple TCP flows in such a scenario involves a use of different TCP ports for the different bearers, e.g. MPTCP main flows and subflows on separate TCP port ranges. This is a working solution, but would require an agreement for example in the standard on port ranges to use.
Thus, there is a need for further solutions to support MPTCP on a wireless device associated with one LTE PDN connection.